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DETAILED ACTION 

Response to Amendments/Remarks 

1 . Applicant's arguments filed on 3/16/2009 with respect the rejection(s) of claim(s) 1-25 
under 35 U.S.C. 103(a) are fully considered, but are not persuasive. 

2. Applicant argues: 

a) "A combination of the cited references fails to show a particular router that is associated with an actual 
time taken for a previous data packet to travel to a previous destination indicated by the previous data packets. In 
addition, the combination of the references fails to show that this actual time is a shortest time among all times 
associated with the routers." (3 rd paragraph from bottom, page 12); 

b) "the Office Action addresses the unclaimed alternative language of "selecting, from a set of routers, a 
particular router that is associated with a first actual path is a shortest path among all paths associated with routers in 
the set of routers", "wherein the first actual path has been updated with a previous actual path taken for a previous 
data packet to travel to a previous destination indicated by the previous data packet." These phrases upon which the 
examination was performed do not appear in Claim 1." (2 nd paragraphs from bottom, page 12); 

c) "the Office Action substitutes the claim term "actual time for a data packet to travel to a destination" 
with "an actual path," which does not appear in Claim l" (last paragraphs of page 12 extending to page 

13); 

d) "The Office Action asserts that RFC 2676 at Section 1.2 page 5 line 8 "teaches the shortest path in 
terms of traveling time." Respectfully, this is incorrect." (last paragraph of page 14); 

e) "Caro's data model is probabilistic. As shown in FIG. 1 on page 325, a network node maintains a 
routing table and a local traffic statistics table. Caro's probabilistic information, i.e., the local traffic statistics table, 
only stores means and variances, as indicated by expression (1) on page 326. The actual time of a data packet is only 
used to compute the means and variances in expression (1). Only the computed statistical results are stored in the 
local traffic statistics table. There is neither a need nor a disclosure in Caro to store actual times of any data packets, 
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as argued by the Office Action. The means and variances in Caro's probabilistic information cannot be used to find a 
router associated with an actual time for a data packet to travel to a destination, as explicitly claimed." (3 rd 
paragraph of page 21). 

In response, Examiner respectfully disagrees: 

a) Caro in view of RFC 2676 discloses every limitation of the claim, as shown in the 
Office Action. The term "actual time" is not defined in Specification. Examiner interprets it as a 
time that is spent on traveling along a particular path. 

b) As stated in Office Action that Caro teaches shortest path and RFC 2676 teaches the 
shortest path is measured in time. The combination of Caro and RFC 2676 teach all the 
limitations of claim. Note that this is a 103 rejection, not a 102 rejection. 

c) The term "actual time" is not defined in Specification. Examiner interprets it as a time 
that is spent on traveling along a particular path, which Examiner calls as the actual path, which 
is clear and reasonable. 

d) RFC 2676 disclose OSPF routing path finding using QoS parameters including delay 
("minimize delay", 2 nd paragraph of Section 3.2, page 18) as the criterion for the shortest path. 
OSPF protocol maintains a routing table from which the shortest path is found based on delay, 
which is interpreted as the shortest path in terms of time. 

e) Caro teaches building and updating a routing table based on a probabilistic model. 
After the routing table is built or updated, a shortest path can be found between any two nodes, 
which does not violate Caro's critical probabilistic model in any way because Caro's model is 
used in building or updating the routing table, not in finding the shortest path. 

Claim Rejections - 35 USC § 103 
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3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

4. Claims 1-7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Teruhi et al 
(US 20030072269, hereinafter Teruhi, which includes IETF standard for RTP, RFC 1889, as 
cited by Teruhi in [0045]) in view of Apostolopoulos, et al., INTF RFC 2676 "QoS Routing 
Mechanisms and OSPF Extensions", August 1999 (hereinafter RFC 2676) 

For claim 1, Teruhi discloses a method of updating a routing table ("routing 
table", [0053]; or suggested by OSPF, [0003], which updates a routing table), 
comprising the computer-implemented steps of: 

selecting, from a set of routers, a particular router that is associated with a first 
actual path is a shortest path among all paths associated with routers in the set of 
routers (selecting a router from a set of routers associated with link 31-33 which has a 
shortest path to a destination, as shown in FIG. 18, that has the shortest path from the 
source node 1 1 to the destination node 12); 

wherein the first actual path has been updated with a previous actual path taken 
for a previous data packet to travel to a previous destination indicated by the previous 
data packet (routing table is updated based on previous traffic, [0007]); 

sending a first data packet (first RTCP-SR sent from node 1 1 to node 12 in FIG. 
9) to the particular router; 
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receiving a second data packet (first RTCP-RR sent from node 12 to node 1 1 in 
FIG. 9) that indicates an second amount of time taken for a destination back to the 
sending router (the time between the first RTCP-RR packet is sent from Node 12 and 
the time it arrives at Node 1 1 , FIG. 9, as disclosed by Section 6.3.2 in page 28 of RFC 
1889); 

wherein the destination indicated by the first data packet is the same as the 
previous destination indicated by the previous data packet (FIG. 10, RTCP-RR packet is 
sent to the destination following a path in the routing table built based on the previous 
data packet); 

wherein the second data packet is sent from the destination indicated by the first 
data packet (FIG. 9, where RTCP-RR is sent from the destination of RTCP-SR); 

wherein the method is performed by one or more computing devices (the router 
shown in FIG. 18). 

Teruhi is silent on the following: 

the shortest path is measured in terms of a shortest time (a first actual time); 

updating the shortest time based on the second time (the trip time of the second 
packet from the destination to the sending router); and 

updating the routing table based on information contained in the second data 
packet. 

In the same field of endeavor (routing), RFC2676 teaches finding the shortest 
path (OSPF, page 1) in terms of traveling time (delay, line 8 of first paragraph in Section 
1 .2, Page 5, which is the time difference between the time that a RTCP packet leaving a 
node A and the time the packet arrives a node B, and is equivalent to the actual 
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traveling time from the node A to the node B) from the routing table that are updated 
based on the received packets ("the QoS routing table that gets built as the algorithm 
progresses ... at each (hop count) iteration, intermediate results are recorded in a QoS 
routing table", 2 nd paragraph, page 12), which is the shortest time of the all the previous 
packets traveled from the set of nodes to the destination node. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to combine Teruhi with RFC2676 to choose the shortest path 
(in term of traveling time) and update the first (shortest) time and the routing table 
based on the information from the second packet for the benefit of efficiency of network 
because they are analogous. 

As to claim 2, Teruhi in view of RFC 2676 discloses the method of Claim 1 , 
further comprising: updating a path associated with both the destination and the 
particular router (by considering the particular router as the sending router in claim 1). 

As to claims 3 and 6, Teruhi in view of RFC 2676 discloses the method of Claim 
1; Teruhi is silent on the second data packet information including the bandwidth 
available on a path taken by the second data packet. 

RFC 2676 teaches the routing packet containing QoS information ("QoS routing", 
1 st paragraph of Page 5), including bandwidth information ("available bandwidth", Line 7 
of Section 1 .2, Page 5). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to include bandwidth information in the second packet for the 
benefit of efficiency of providing better routing options. 



Application/Control Number: 10/645,255 Page 7 

Art Unit: 2462 

As to claims 4 and 7, Teruhi in view of RFC 2676 discloses the method of Claim 
1 , whether a path taken by the first data packet is feasible (a path found based on 
updated routing table is feasible). 

As to claim 5, Teruhi in view of RFC 2676 discloses the method of Claim 1 , 
further comprising: updating, based on information contained in the second data packet, 
a list of routers that indicates all routers in a path taken by the first data packet to a 
router that sent the first data packet to a present router (This is equivalent to finding the 
shortest path based on the updated routing table with the information of the second data 
packet). 

5. Claims 8 and 18-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 
1247 "OSPF Version 2", July 1991 (hereinafter RFC 1247) in view of RFC 2676. 

For claims 8 and 18-20, RFC 1247 discloses a method, a computer storage 
medium, an apparatus for updating a routing table ("a routing table", page 1, 2 nd 
paragraph), comprising: 

A network interface (the network interface of the router OSPF router, page 1 , 2 nd 
paragraph) that is coupled to a data network for receiving one or more packet flows 
therefrom; a processor (CPU of "OSPF router", page 1, 2 nd paragraph) executing 
instructions 

for each neighbor router in a set of neighbor routers (neighboring routers, page 
4), selecting a shortest path to a specified destination via a set of neighbor routers 
(shortest paths, 3rd paragraph of 1 .1 , page 2); 
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wherein the shortest path has been updated with a previous data packet to travel 
to the specified destination (Link State Update, table 8, page 26, where the routing is 
updated based previous routing data packets) ; 

send a first data packet to the specified destination (sending Link State Request 
packet to the destination, 3rd paragraph of page 74); 

receiving a second data packet from the specified destination (receiving sending 
Link State Request packet from the destination, 3rd paragraph of page 74); 

wherein the second data packet is sent from the destination (FIG. 10, where 
RTCP-RR is sent from the destination of RTCP-SR); 

updating the routing table based on information contained in the second data 
packet ("updating the necessary part of its database", 3rd paragraph of page 74). 

RFC 1247 is silent on the measurement parameter for the shortest path in 
routing table is the time (or delay) for a packet to travel from a source router to a 
destination router. 

RFC 2676 discloses using delay (line 8 of Section 1 .2, Page 5) as one of QoS 
parameters for routing measurement (the shortest delay includes the information of 
delay times of all the previous packets to the destination), which are used to the 
updating routing table. RFC 2676 teaches enhancement of OSPFv2 by RFC 1247. It 
would be obvious for one skilled in the art to combine RFC 1247 with RFC 2676 to use 
time delay in the routing table, and update the routing table for the shortest path in term 
of delay time between two routers. 
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Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to using delay time as routing measurement parameters to 
update routing table. 

6. Claim 1-25 are rejected under 35 U.S.C. 103(a) as being 103(a) as being unpatentable 
over Gianni Di Caro et al, "AntNet: Distributed Stigmergetic Control for Communications 
Networks", Journal of Artificial Intelligence Research, 12/98 (hereinafter Caro) in view of RFC 
2676 (which includes the recited RFC 1247). 

For claim 1, Caro discloses a method of updating a routing table ("the routing 
table", page 327, step 3), comprising the computer-implemented steps of: 

sending a first data packet from a sending router to a given destination via a 
particular router so that the packet arrives at the destination (sending forward ant, step 
1 of page 326, line 1-3); wherein the first time has been updated with a previous time 
taken for a previous data packets (the routing table is built based on previous routing 
data packets); 

receiving a second data packet that indicates an second amount of time from 
taken for the destination back to the sending router (receiving backward ant, step 5 of 
page 327); 

selecting the path according to a criterion that the first packet is predicted to 
reach the destination, wherein the second data packet is sent from the destination 
indicated by the first data packet ("The backward ant takes the same path as that of its 
corresponding forward ant, but in the opposite direction", step 6, page 328); 
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updating the shortest time based on the second time ("updates .. the traffic M_k", 
step 7, page 328 in view of "The model M maintains absolute distance/time estimates", 
3 rd paragraph, page 326); and 

updating the routing table based on information contained in the second data 
packet ("updates ... the routing table", step 7, page 328-329); 

wherein the method is performed by one or more computing devices (the routers 
on the path upon which forward and backward ants travel). 

Caro is silent on the criterion for the shortest path is based on the shortest time 
(the first time, which is a shortest time that the first packet is predicted to reach the 
destination); 

In the same field of endeavor (routing), RFC2676 teaches routing the shortest 
path in term of traveling time (delay, line 8 of first paragraph in Section 1 .2, Page 5). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to combine Caro with RFC 2676 to choose the shortest path (in 
term of traveling time) and update the first (shortest) time and the routing table based on 
the information from the second packet for the benefit of efficiency of network because 
they are analogous. 

As to claim 2, Caro in view of RFC 2676 discloses the method of Claim 1 , Caro 
further discloses the method comprising: updating a path associated with both the 
destination and the particular router ("updates ... the routing table", step 7, page 328). 

As to claims 3 and 6, Caro in view of RFC 2676 discloses the method of Claim 
1 , but are silent on the second data packet information including the bandwidth 
available on a path taken by the second data packet. 
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RFC 2676 teaches the routing packet containing QoS information ("to support 
QoS", Line 3 of Section 1.2, Page 5), particularly bandwidth information ("available 
bandwidth", Line 7 of Section 1 .2, Page 5). 

One skilled in the art would have been motivated to apply the teaching by RFC 
2676 to the second packet to provide additional information for better routing options. 
Furthermore, OSPF technology taught by 2676 is cited by the applicant in the 
disclosure. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to include bandwidth information in the second packet for the 
benefit of efficiency of providing better routing options. 

As to claims 4 and 7, Caro and RFC 2676 disclose the method of Claim 1 , 
whether a path taken by the first data packet is feasible (a path predicted to take a 
shortest time from the source node to the destination node is always feasible). 

As to claim 5, Caro and RFC 2676 disclose the method of Claim 1 , Caro further 
discloses the method comprising: updating, based on information contained in the 
second data packet, a list of routers that indicates all routers in a path taken by the first 
data packet to a router that sent the first data packet to a present router ("updates ... 
the routing table", step 7, page 328-329). 

For claim 8 and 18-20, Caro discloses a method, an apparatus for updating a 
routing table (steps 1-7, page 326-330), comprising: 

a network interface (the network interface of the router holding the routing table) 
that is coupled to a data network for receiving one or more packet flows therefrom; a 
processor (CPU of the router holding the routing table) executing instructions 
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for each neighbor router in a set of neighbor routers (suggested by "every 
network node", line 1 of step 1 , page 326), selecting a path to a specified destination 
via a set of neighbor routers (line 1-2 of step 3 and step 5, page 327); 

wherein the shortest path has been updated with a previous time taken for a 
previous data packet to travel to the specified destination (line 5-30 of page 331 , 
determining is based on M=Local traffic model and T=Node routing table); 

send a first data packet to the specified destination ("destination node is 
reached", step 5, page 327; or LanuchForwardAnt(destination_node, source_node), line 
13 of page 331); 

receiving a second data packet from the specified destination; wherein the 
second data packet is sent from the specified destination (suggested by "The backward 
ant takes the same path as that of its corresponding forward ant, but in the opposite 
direction", step 6, page 328) 

updating the routing table based on information contained in the second data 
packet (step 7, page 328; or UpdateLocalRoutingTable, line 26 of Page 331). 

Caro discloses using trip time as parameter in routing table ("How to Score the 
Goodness of the ant's Trip Time", Section 4.2, title and 1 st paragraph, page 330), but 
does not explicitly disclose that the path is the shortest in terms of delay time from a 
source router to a destination router and the shortest amount of time is updated with 
data packet travel to the specified destination. 

In the same field of endeavor, RFC 2676 discloses OSPF extensions on routing 
based on path QoS parameters (lines 1-5 of page 3). Since time delay (trip time) is one 
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of QoS parameters, it would have been obvious to one skilled in the art to use the 
shortest time (delay time) as the criteria for the shortest path. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to combine Caro with RFC 2676 to selecting a particular 
neighbor router that has a lowest amount of delay time from source node to the 
destination node in searching the best routing. 

For claim 9, Caro discloses a method of updating a routing table (Node routing 
table, page 331, line 6), the method comprising the computer-implemented steps of: 

for each neighbor router in a set of neighbor routers predicted to be required for a 
data packet to travel to a specified destination ("every network node", line 1 of step 1 , 
page 326), associating the neighbor router with an amount of time ("elapsed_time", 
page 331 , line 1 9; or step 2 of page 326); 

receiving a forward ant data that indicates the specified destination (suggested 
by "The backward ant takes the same path as that of its corresponding forward ant, but 
in the opposite direction", step 6, page 328; or algorithm shown in page 331); 

selecting, based on one or more first specified criteria (goodness of ant's travel 
time, title and first paragraph of Section 4.2, page 330; or step 3 of page 327), a subset 
of the set of neighbor routers (from page 331 , line 14-20 where forward ant can only be 
passed to neighboring routers one at a time; selecting from the routing table a subset of 
neighbor routers through which paths to the destination go); 

in response to receiving the forward ant data packet, selecting, from the subset 
of neighbor routers, to the specified destination, among amounts of time associated with 
neighbor routers in the subset of neighbor routers (the paths from the routing table are 
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updated based on received forward ant data packet, first paragraph of Section 4.2, page 
330; or "updates the corresponding statistics and the routing table", step 7); 

wherein the amount of time has been updated with a previous amount of actual 
time taken for a previous data packet to travel to the specified destination ("step 7 i) of 
page 328, where Mk that includes travel time information is updated based on previous 
travel time of ants; or algorithm shown in page 331 ); 

sending the forward ant data packet to the particular neighbor router ("destination 
node is reached", step 5, page 327; or LaunchForwardAnt (destination_node, 
source_node), lines 10-12, page 331); 

receiving a backward ant data packet that indicates a second amount of time 
taken for the forward ant data packet to travel to the specified destination ("The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328; the travel time is the second amount of time); 

wherein the backward ant data packet is sent from the specified destination ("The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328); 

determining, based on information indicated in the backward ant data packet, 
whether one or more second specified criteria are satisfied (line 5-30 of page 331 , 
determining a path based on criteria specified in M=Local traffic model and T=Node 
routing table); and 

if the one or more second specified criteria are satisfied (a second time criteria 
used to find proper path based on M and T; notice that criteria used for selecting paths 
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depend on user requirements and may have multiple values), then performing steps 
comprising: 

updating the first amount of time based on the second amount of time 
(suggested by UpdateLocalTrafficModel, line 24 of Page 331 ; where traffic model is 
updated); and 

if one or more third specified criteria are satisfied (suggested by "The 
backward ant takes the same path as that of its corresponding forward ant, but in the 
opposite direction", step 6, page 328, which indicates the backward ant knows whether 
the path taken by the forward ant is followed, which is equivalent to the path feasibility 
flag), then updating, based on information indicated in the backward ant data packet, 
the routing table (suggested by UpdateLocalRoutingTable, line 26 of Page 331). 

Caro does not explicitly disclose selecting a particular neighbor router that is 
associated with a first amount of time that is a lowest amount of time, but defines a 
goodness in terms of trip time ("as estimated using the associated trip time", line 27-34 
of page 329) that is used as a measure for determining routing between nodes. 

In the same field of endeavor, RFC 2676 discloses OSPF extensions on routing 
based on path QoS parameters (lines 1-5 of page 3). Since time delay is one of most 
important QoS parameters, it would have been obvious to one skilled in the art to use 
the shortest trip time (delay time) as the criteria for the shortest path. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to combine Caro with RFC 2676 to selecting a particular 
neighbor router that has a lowest amount of delay time from source node to the 
destination node in searching the best routing. 
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As to claim 10, Caro in view of RFC 2676 discloses the method of Claim 9, 
wherein the one or more first specified criteria comprise a criterion that no neighbor 
router in the subset of neighbor routers is contained in a list of routers that have already 
been visited by the forward ant data packet ("choosing among the neighbors it did not 
already visit", line 1-2 of page 327). 

As to claim 11, Caro in view of RFC 2676 discloses the method of Claim 9, Caro 
further discloses the method comprising: 

determining whether any neighbor router in the set of neighbor routers is 
associated with an amount of time that is lower than the first amount of time ("as 
estimated using the associated trip time", line 27-34 of page 329); and 

if any neighbor router in the set of neighbor routers is associated with an amount 
of time that is lower than the first amount of time, then updating the forward ant data 
packet to indicate a present router in a loop-avoidance router field of the forward ant 
data packet (cycle avoidance, step 4 of page 327, line 1-3). 

As to claim 12, Caro in view of RFC 2676 discloses the method of Claim 1 1 , 
Caro further discloses wherein a loop-avoidance router field ("memory of their paths and 
of the traffic conditions found", lines 1-2 of step 2 in page 326) of the backward ant data 
packet indicates a router indicated by the loop-avoidance router field of the forward ant 
data packet (notice that a backward ant packet has the same structure as forward ant 
packet). 

As to claim 13, Caro in view of RFC 2676 discloses the method of Claim 1 2, 
Caro further discloses wherein the one or more second specified criteria comprise a 
criterion ("trip time", line 10 of page 329) that the router indicated by the loop-avoidance 
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router field of the backward ant data packet is not contained in a list of routers that the 
forward ant visited after visiting a present router (step 3 of page 327, line 1-2; notice that 
a backward ant packet has the same structure as forward ant packet). 

As to claim 14, Caro in view of RFC 2676 discloses the method of Claim 9, but is 
silent on wherein the one or more specified criteria comprise a criterion that the second 
amount of time is lower than any other amount of time, relative to the specified 
destination, among amounts of time associated with neighbor routers in the set of 
neighbor routers. 

However, the criterion that the second amount of time is lower than any other 
amount of time is used in OSPF (disclosed by RFC 2676) in determining the shortest 
path in term of time. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to specify criterion that the second amount of time is lower than 
any other amount of time in order to find the shortest path. 

As to claim 15, Caro in view of RFC 2676 discloses the method of Claim 9, but 
are silent on the method comprising: determining whether a router from which the 
backward ant data packet was received matches a router associated with the 
destination in the routing table; and if the router from which the backward ant data 
packet was received does not match the router associated with the destination in the 
routing table, then updating a path feasibility flag of the backward ant to indicate that a 
path taken by the forward ant is not feasible. 

However, the method requires the forward ant packet and the backward ant 
packet go through the same route (in opposite direction). If the backward ant packet 
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cannot following the same route as the forward ant packet, the ant packet will be 
destroyed according to Caro ("if an ant is forced to return to an already visited node, the 
cycle's nodes are popped from the ant's stack and all the memory about them is 
destroyed", step 4 of page 327). It is a common practice in the art that one way of 
destroying/delete a packet is to set a flag of the packet so that it can be destroyed at 
proper time or location (such as taught by Tarin, US 2001/0000536 A1 , "deleted cells 
are marked by a flag", [247]). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to set a flag of the received backward ant packet if routing 
information of the packet does not match the routing table of the router in order to 
comply with the protocol. 

As to claim 16, Caro in view of RFC 2676 discloses the method of Claim 15, 
Caro further discloses the one or more third specified criteria comprise a criterion that 
the path feasibility flag of the backward ant indicates that the path taken by the forward 
ant is feasible (suggested by "The backward ant takes the same path as that of its 
corresponding forward ant, but in the opposite direction", step 6, page 328, which 
indicates the backward ant knows whether the path taken by the forward ant is followed, 
which is equivalent to the path feasibility flag). 

As to claim 17, Caro in view of RFC 2676 discloses the method of Claim 9, Caro 
further discloses the one or more third specified criteria comprise a criterion that a path 
taken by the forward ant data packet from a present router to the specified destination 
does not include any routers that are identified in a potential upstream node list 
(suggested by "The backward ant takes the same path as that of its corresponding 



Application/Control Number: 10/645,255 Page 19 

Art Unit: 2462 

forward ant, but in the opposite direction", step 6, page 328, which indicates the 
backward ant knows whether the path taken by the forward ant is followed, which is 
equivalent to the path feasibility flag). 

As to claim 21, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses the stored sequences of instructions include instructions which, 
when executed by the processor, cause the processor to further carry out: updating, 
based on information contained in the second data packet, a path associated with both 
the destination and the particular router ("updates ... the routing table", step 7, page 
328-329 or UpdateLocalRoutingTable, line 26 of Page 331; the routing table includes all 
the paths, including a path associated with both the destination and the particular 
router). 

As to claim 22, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 
which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet ("updates ... the 
routing table", step 7, page 328-329 or UpdateLocalRoutingTable, line 26 of Page 331), 
an indication of an amount of bandwidth available ("characterized by a bandwidth", lines 
10-1 1 of page 322) on the path taken by the second data packet (the path is disclosed 
by "The backward ant takes the same path as that of its corresponding forward ant, but 
in the opposite direction", step 6, page 328). 

As to claim 23, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 



Application/Control Number: 10/645,255 Page 20 

Art Unit: 2462 

which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet ("updates ... the 
routing table", step 7, page 328-329 or UpdateLocalRoutingTable, line 26 of Page 331), 
whether a path taken by the first data packet is feasible (suggested by "The backward 
ant takes the same path as that of its corresponding forward ant, but in the opposite 
direction", step 6, page 328; a mechanism that ensures the path is feasible based on 
the updated routing table). 

As to claim 24, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 
which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet, a list of routers 
that indicates every router in a path taken by the first data packet from a router that sent 
the first data packet to a present router (suggested by "The backward ant takes the 
same path as that of its corresponding forward ant, but in the opposite direction", step 6, 
page 328). 

As to claim 25, Caro in view of RFC 2676 discloses the method of Claim 20, 
Caro further discloses wherein the stored sequences of instructions include instructions 
which, when executed by the processor, cause the processor to further carry out: 
updating, based on information contained in the second data packet to indicate an 
amount of bandwidth available (routing table is "characterized by a bandwidth", lines 10- 
1 1 of page 322) on the path taken by the second data packet (bandwidth available is 
considered as a criterion of feasible path in algorithm specified in steps 1-7 of pages 
326-330, which includes routing based on bandwidth). 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Jianye Wu whose telephone number is (571)270-1665. 
The examiner can normally be reached on Monday to Thursday, 8am to 7pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Seema Rao can be reached on (571)272-3174. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
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Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Jianye Wu/ 
Examiner, Art Unit 2462 



/Kevin C. Harper/ 

Primary Examiner, Art Unit 2462 



